As collecting and storing data from a variety of sources has become easier and cheaper in recent years, business decisions are increasingly being made in a data driven manner. Over recent decades fairly sophisticated data processing applications have been developed using databases of various types, including traditional relational databases, object-oriented databases, non-relational or “NoSQL” databases, and the like. In some cases, such data processing applications have been designed to handle millions of even billions of data records.
Typically, developing and changing applications that rely on database systems is a non-trivial exercise, usually involving teams of programmers and long development cycles. Large well-financed organizations may be able to hire enough programming staff to develop and maintain the applications for various target environments, or outsource the work of developing and maintaining the applications. However, for a “long tail” of relatively small teams or individuals, the costs associated with developing full-fledged data management applications using conventional database systems may sometimes be prohibitive. Furthermore, interacting with the database applications may sometimes require expertise in languages (such as various versions of the Structured Query Language in the case of relational databases) in which expertise may sometimes be lacking in small teams.
In contrast to large and complex database systems, spreadsheet applications offer an easier-to-use approach towards managing data. Spreadsheets offer a tabular view of data, often with fewer restrictions (for example on the types of data that can be stored in a given row or column) than database systems, and allow many common types of calculations to be performed on data sets using formulas that are relatively easy to understand and modify. However, as the size of the data sets to be managed increases, especially in scenarios in which hierarchical and relational associations between different sets of data need to be incorporated into the applications, some traditional spreadsheet programs may not necessarily work well.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to. When used in the claims, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof.